fix(#5192): bundle the JasperFx.Events.SourceGenerator 2.42.1 published-types fix - #5196
Merged
Merged
Conversation
…ed-types fix The generator registers an EventProjection's discovered published document types (#4166) by writing into the user's partial class. It used to do that by emitting a parameterless constructor, which fails for exactly the projections that need dependencies injected -- the ones registered through AddProjectionWithServices. A primary constructor made it a build break: C# requires every other constructor to chain through the primary one, so `partial class MyProjection(ILogger logger) : EventProjection` failed to compile with CS8862 inside the generated <T>.TypeRegistration.g.cs. That is what #5192 reported. An ordinary injected constructor made it a silent no-op: the container calls the dependency-taking constructor, so the generated parameterless one never ran and the published types went unregistered -- which also left #626's teardown registration nothing to register. #637 moves registration onto an override of ProjectionBase.PublishedTypes(), which does not care how the instance was constructed. Only the source generator pin moves, 2.41.0 -> 2.42.1. It is analyzer-only, declares no dependencies, and Marten bundles its dll into Marten.nupkg, so its version is independent of the runtime family's -- which stays at 2.41.0 until Marten adopts the strong-typed identity compliance suite from 2.42.0. The generator is byte-identical from 2.38.0 through 2.42.0, so this is an isolated swap of that one fix. The regression test covers both shapes. The primary-constructor half is enforced by compilation itself: against the older generator the test file does not build, with the same CS8862 the issue reported. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde
jeremydmiller
force-pushed
the
fix/5192-source-generator-bump
branch
from
August 6, 2026 09:50
6a4ffd4 to
bef3268
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #5192. Consumes jasperfx#637, shipped in JasperFx 2.42.1.
The bug
The bundled
JasperFx.Events.SourceGeneratorregisters anEventProjection's discovered published document types (#4166) by writing into the user's partial class. It used to do that by emitting a parameterless constructor — which fails for exactly the projections that need dependencies injected, i.e. the ones that have to be registered throughAddProjectionWithServices.A primary constructor made it a build break. C# requires every other constructor to chain through the primary one, so this failed to compile with CS8862 inside the generated
<T>.TypeRegistration.g.cs:That is what #5192 reported.
An ordinary injected constructor made it a silent no-op. The container calls the dependency-taking constructor, so the generated parameterless one never ran and the published types went unregistered — which also left #626's teardown registration nothing to register. Confirmed on 9.22.4:
#637 moves registration onto an override of
ProjectionBase.PublishedTypes(), which does not care how the instance was constructed.Regression window
Marten 9.22.2 builds, 9.22.3 does not. 9.22.3 bundles a generator built from JasperFx.Events 2.38.0, which included #611 — published-type discovery became semantic. Before that only an explicit
Store<Doc>(x)produced a registration and the far more commonStore(doc)produced none, so the constructor was rarely emitted at all. The constructor defect itself is older:Store<Doc>(x)plus a primary constructor breaks on 9.22.0 too.Why only the source generator pin moves
JasperFx.Events.SourceGeneratorgoes 2.41.0 → 2.42.1 while the rest of the JasperFx line stays at 2.41.0. That package is analyzer-only, declares no dependencies, and Marten bundles its dll intoMarten.nupkg(_BundleEventsSourceGeneratorAnalyzer, #4557), so its version is independent of the runtime family's — which should stay at 2.41.0 until Marten adopts the strong-typed identity compliance suite that landed in 2.42.0. The generator is byte-identical from 2.38.0 through 2.42.0, so this is an isolated swap of that one fix rather than a version of drift. The reasoning is recorded in a comment on the pin itself.Behavior change worth knowing
The generator used to skip registration entirely when the class already had an explicit parameterless constructor — a guard that existed only because you cannot add a second one. An override has no such conflict, so those projections now get their published types registered too. That is the intended #4166 behavior, but it means this upgrade can newly provision document storage, and newly register teardown targets under #626, for a projection that was quietly getting neither.
Verification
Bug_5192_event_projection_with_injected_dependenciescovers both shapes plus a store-level assertion that the discovered types reachAllPublishedTypes().The primary-constructor half is enforced by compilation itself — pinned back to the older generator, the test file does not build, with exactly the error the issue reported:
Locally against the published 2.42.1: the three new tests pass, full
Marten.slnxbuilds, andEventSourcingTests(net9.0) runs 1627 passed / 0 failed / 7 skipped.(One incidental note: the test class is
partialbecause the generator wraps a nested projection's emitted members in their containing types. Pre-existing generator behavior, not introduced here.)🤖 Generated with Claude Code
https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde